1. Field of the Invention
The present invention relates to the field of debug circuitry in a data processing apparatus. More particularly, the invention relates to the control of watch point units within debug circuitry.
2. Description of the Prior Art
A known programming model consists in associating a set of data with a semaphore. The state of the set of data, and derived from this the usage that can be made of this set of data, is derived from the state of the semaphore. For example, when multiple tasks must be performed on a set of data, the semaphore may reflect which of these tasks have already been performed, and which have not yet been performed.
In the context of software threads, the concept of the semaphore may be further extended to include information that a thread currently “owns” the data set. Owning a data set provides a given set of rights, while not owning it provides another set of rights. For example, a thread producing data for another thread will take the ownership of the semaphore. This ownership gives it rights to write the set of data. When taking the ownership of the semaphore, the thread should also set the state of said semaphore to reflect the fact that the set of data is being produced, hence indicating to other threads that the set of data is not available. When the thread producing the set of data completes its task, it both releases the ownership of the semaphore and changes its state to reflect the fact that the data is available to the other threads. The other threads will read this set of data to complete their own task.
Enforcing this programmer's model is not an easy task. It is known, during the development of such software applications, to face what are called data corruption problems. Corruption may have multiple sources. For example, one known problem is when a thread consuming some data produced by another thread starts reading this data before the producer has effectively produced it, or some part of it.
Another known data corruption problem occurs when multiple threads, having to work on the same set of data, work concurrently instead of sequentially on this set of data, modifying this data at the same time, one overwriting the data produced by the other thread.
Hardware support for debugging such software applications, and tracking such errors, mainly resides in three components: breakpoints, watch points and trace. It is known to use watch points to trap accesses to a given set of data (one or more data values). To debug a data corruption problem, a watch point is set to the set of data. This watch point can be set to track only some kinds of accesses so as to limit the number of false triggers. The watch point unit is then programmed to not report allowed accesses, or in a way that it filters most of the allowed accesses. Multiple conditions may be set. Such conditions may include the nature of the access. An identity field may also be provided, indicating the thread to which these conditions apply, or to which the conditions do not apply.
It is known to instrument the software routines used to access semaphores, so that they update the condition used by the watch point unit according to the new state of the semaphore, or further with the identity of the thread owning the semaphore, if any.
The cost of the instrumentation of these routines is a major drawback of such known techniques. It may require modification to the Operating Systems, and this modification may not necessarily be accepted by the vendor of the Operating System. It also requires modification to be made to the applications sharing the set of data, so that they all update the information associated with the watch point unit. This may require a significant amount of work as the procedure call for such instrumented routines may differ from the standard one used when the application is not being debugged. In some cases, it may even not be feasible, when the source code of a given application is not available, for example when this application is provided by a third party.
When these multiple threads run on multiple processors, as is the case on Symmetric Multi-Processing systems (SMP) for example, the watch point units associated with each of the multiple processors must be synchronised to track the same data set with the same set of conditions. This is a further drawback of the prior art, as synchronising the watch point units on each processor requires further modifications to the Operating System, and introduces a serialisation point in the program flows. This serialisation may impact the visibility of the bug, making it less likely to occur, hence less likely to be found. In some cases, this serialisation fully removes the occurrence of the bug, which then cannot be tracked using this technique.
A known way of implementing these instrumented routines over an SMP system is described hereafter, in a simplistic scheme.
When software thread takes the ownership of a semaphore, the routine dealing with taking that ownership subsequently performs the following actions, prior to returning ownership to the calling thread:                Get the identification of the thread currently running.        Update the local watch point unit, so that, for accesses made by this thread, it uses a given set of conditions, and for accesses made by other threads, it uses a further set of conditions. This is done through a call to the Operating System.        Update the watch point units located in the other processors of the cluster of processors accordingly. This is done by another call to the operating system, which in turn must broadcast a message to the other processors, forcing them to enter a privileged mode and calling the Operating System locally.        
This also requires that any thread dealing with the memory location being watched at is instrumented in this way.
It should be noted that in this description, the term semaphore should be understood in its widest sense, describing any mechanism used for asserting the state of a set of data, or assisting in the use of a shared set of data, and as such, for example, mutex, locks, spinlocks and equivalent software objects are all considered as forms of semaphore.
It should also be noted that while the description uses the terms “software threads” or “software applications”, it is not restricted to threads or applications as sometimes considered in strict Operating Systems wording, but should instead be understood as any set of instruction sequences able to share a set of data with another set of instruction sequences. As such, a non exhaustive list of what the present invention covers includes programs running on top of an Operating Systems, multiple Operating Systems, multiple parts of the same program or of the same Operating System, multiple threads of the same application and multiple instances of the same process or program.